[アップデート] 「最小権限の実装」が容易に!過去の CloudTrail イベントに基づいて IAM ポリシーを生成できるようになりました
コンバンハ、千葉(幸)です。
IAM Access Analyzer により、過去のアクティビティイベントに基づいて IAM ポリシーの生成ができるようになりました!
「必要最小限の権限に絞る」というアプローチが取りやすくなりましたね。
激アツアップデートなので冗長構成で記事を書いています。(平たく言うと被った。)あわせてご参照ください。
何が嬉しいのか
「今はユーザーに広めの権限を与えているけど、必要な権限のみを与えるように絞っていきたいなぁ」
「必要な権限ってなんだろう。洗い出すのが難しいな」
「過去 30 日間で一通り必要な操作はしたから、それができれば十分だな」
「実際の操作を洗い出してそのままポリシーにしてくれたりしたらいいのに」
はい、それができるようになりました。
「最小権限の実装」は、 AWS を使用する上で遵守すべきベストプラクティスです。小さな権限から始めて徐々に必要な権限を付け足していく、というアプローチもあれば、広めに与えてから絞っていく、というアプローチもあります。どんなアプローチでも、ポリシーの精査やチューニングにはそれなりの労力が発生するものでした。
今回のアップデートにより、以下のようなケースでのチューニングが簡単に行えるようになりました。
- 開発環境(あるいは開発「期間」)では広めに権限を与えている
- 開発環境では一通り必要な操作を実行している
- 本番環境に移行する際に、必要最小限の権限に絞る必要がある
Trail に記録された過去のイベントから必要な権限を持つポリシーのテンプレートを生成してくれるため、それをカスタマイズして使うことができます。
ありがとうございます……!
全体イメージ
アクセスアクティビティに基づいたポリシー生成について補足事項
以下ページに各種情報がまとまっています。
「知っておきべきこと」として以下が挙げられています。
- Cloud Trail が有効になっていることが前提
- ポリシーを生成する IAM エンティティ(ユーザー/ロール)と同じアカウントで Trail を有効にすること
- クロスアカウントは不可
- ポリシー生成の時間を短縮するためには分析する期間を短めにすること
- 監査目的でポリシー生成を使用してはならない
- 過去のアクティビティに基づいてポリシーが生成されるからといって、すべてが網羅されるわけではありません
- ポリシーを生成できるのは IAM Console で一つまで
- 複数の IAM エンティティに対するポリシー生成を同時には実行できません
- 生成されたポリシー(テンプレート)はコンソールで最大 7日間確認可能
- クォータについては以下参照のこと
- IAM and STS quotas - AWS Identity and Access Management
- 分析できる Trail の期間は最大 90日分
- 1日に生成できるポリシーは5つまで など
その他、個人的に以下を付け足しておきます。
- IAM Access Analyzer 用のサービスロールの設定が必要
- 初回実行時に自動作成可能
- IAM Access Analyzer アナライザーの作成は不要
- アクションレベルまで洗い出してくれるサービスとそうでないサービスがある
まぁいろいろ書きましたが、無料ですからね、とりあえず使っちゃえばいいんですよ。
やってみた
特定の IAM ロールに対しポリシー(テンプレート)の生成を行い、それを基に実際のポリシーを作成・アタッチしてみます。
大まかに以下の流れとなります。
- 対象の IAM ユーザー/ロールの画面からポリシー生成リクエストを実行
- 遡る期間や、ベースにする Trail 証跡を選択
- 初回は Access Analyzer 用のサービスロールをセットアップ
- 生成されたポリシーから実際のポリシーを作成
- 権限の確認
- 必要に応じてポリシーの修正
- 作成およびアタッチ
ポリシーの生成リクエストの実行
IAM ロールの詳細画面の中に、CloudTrail イベントに基づいてポリシーを生成の項目が追加されています。
展開し、「ポリシーの生成」を押下します。
以下項目を指定し、「ポリシーを生成」を押下します。
- 期間の指定
- 分析対象の CloudTrail 証跡
- 使用するサービスロール
今回は初回のため、新しいサービスロールがあわせて作成されます。次の画面に遷移する前に、ロール作成が進行中であることが表されます。
ちなみにロールにアタッチされるポリシーは以下の通りです。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "cloudtrail:GetTrail", "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:GenerateServiceLastAccessedDetails", "iam:GetServiceLastAccessedDetails" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::{{cloudtrail-bucket}}", "arn:aws:s3:::{{cloudtrail-bucket}}/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "arn:aws:kms:{{region}}:{{account}}:key/{{key}}" ], "Condition": { "StringLike": { "kms:ViaService": "s3.*.amazonaws.com" } } } ] }
ロールの詳細画面に戻ると、ポリシー生成が進行中である旨が表示されています。
数分待ちましょう。
ちなみに
生成が進行中の状態で他の IAM エンティティで生成を試みるとエラーになります。「一度に一つまで」という制約がありましたね。欲張らないでください。
生成されたポリシーの確認
今回は 7分程度で生成が完了しました。期間を長めに指定するとその分時間がかかるようなのでご留意ください。(今回は 7日で指定しています。)
「生成されたポリシーを表示」を押下します。
大きく以下のステップに分かれます。
- アクセス権限の確認
- アクセス権限のカスタマイズ
- ポリシーの確認および作成
1. アクセス権限の確認
分析に基づきいくつかのアクションがリスト化されています。下に画面が続きます。
サービスによっては、上記のようにアクションレベルでの洗い出しに対応していません。その場合、この画面でアクションを手動で追加していくことになります。
追加する際のイメージは以下の通り。次のステップに進みます。
2. アクセス権限のカスタマイズ
JSON のエディターの画面に遷移するため、ここで独自に修正を行えます。
先日のアップデートで対応した「ポリシー検証」機能がここでも使用できます。デフォルトでエラーが検知されていますね、、。
生成された段階では、リソースが以下のように変数を用いるように設定されている箇所があります。
arn:aws:ec2:${Region}:${Account}:instance/${InstanceId}
そのままでは使用できない変数が含まれていたために検知されたエラーであったため、修正し次に進みます。
ちなみにエラーとして検知されなくとも(ポリシー構文としては問題なくとも)変数が利用されている箇所は他にもありました。
生成されたポリシーのResource
部は特に注意して確認し、環境にあわせてカスタマイズしてください。
3. ポリシーの確認および作成
最後のステップです。
ポリシー名や、必要に応じて説明・タグを入力します。
作成と同時に IAM エンティティにアタッチするかを選択し、ポリシーの作成を実行します。
作成&アタッチができました!
新規作成したポリシーに切り替えて操作に支障がでないか、経過観察を行いましょう。
最小権限の実装に活用しよう
IAM Access Analyzer による、アクセスアクティビティに応じたポリシー生成を確認しました。
ワンクリックでそのまま使えるポリシーを生成、とまでは行きませんが、カスタマイズするためのテンプレートを実績に応じて生成してくれる、というのは嬉しいですね。以下の注意点はおさえておきましょう。
- アクションレベルでリスト化してくれるサービスとそうでないものがある
- リソース部は独自に指定が必要
- 例えば過去に特定の EC2 インスタンスに対してのみ操作をしていても、それは生成したポリシーには反映されない
「いつかはやらなきゃな……」と思いながらも最小権限への絞り込みに手をつけられていなかった方は、これを機にポリシーの見直しをかけてみてはいかがでしょうか。
以上、千葉(幸)がお送りしました。